Skip to content

[pull] main from withastro:main - #681

Merged
pull[bot] merged 6 commits into
code:mainfrom
withastro:main
Aug 12, 2026
Merged

[pull] main from withastro:main#681
pull[bot] merged 6 commits into
code:mainfrom
withastro:main

Conversation

@pull

@pull pull Bot commented Aug 12, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

thelazylamaGit and others added 6 commits August 12, 2026 15:25
…17611)

* fix(dev): collect fresh CSS in fallback environments

* add changeset

* improvements

* fix tests
…#17659)

The fonts plugin embeds the ephemeral HTTP server's AddressInfo (including
an OS-assigned port) into the font-file-url-resolver virtual module. Since
the port changes every build, the incremental build plugin's dependency
hash was non-deterministic, silently defeating all caching for any route
that imports <Font />.

Fix: assign the address to a variable named with a known token
(__ASTRO_FONTS_SERVER_ADDRESS__) and have the incremental plugin strip
the variable declaration before hashing, following the same pattern as
resolveAssetPlaceholders for volatile asset emit handles.

Fixes #17626

Co-authored-by: Matthew Phillips <matthew@matthewphillips.info>
Co-authored-by: Emanuele Stoppa <estoppa@cloudflare.com>
…ency limiting and retry (#17650)

Add a concurrency-limited file reader (`readFileWithRetry`) to `emitImageMetadata`
that caps concurrent `fs.readFile` calls to 200 and retries transient OS errors
(EMFILE, ENFILE, EAGAIN, EBUSY) with exponential backoff. The bare `catch` block
that previously swallowed all errors now only returns `undefined` for ENOENT (file
not found), re-throwing other errors with the real OS message instead of the
misleading "Could not find requested image... Does it exist?"

Fixes #17649
Co-authored-by: tianrking <tianrking@users.noreply.github.com>
* fix: detect stale dev server lock files when the recorded PID was reused

The lock file liveness check relied on process.kill(pid, 0), which only
proves that some process owns the PID. After a Docker container restart
the PID is quickly reused by an unrelated process while the lock file
persists on the volume mount, so astro refused to start.

The lock file now records the kernel start time from /proc/<pid>/stat
alongside the PID, and the check verifies both. Lock files written by
older versions are only treated as stale when the recorded process
clearly started after the lock file was written (5s margin for soft
clocks). Platforms without /proc keep the previous PID-existence check.

Closes #17656

* fix: verify lock file process identity across platforms

---------

Co-authored-by: Matthew Phillips <matthewphillips@cloudflare.com>
@pull pull Bot locked and limited conversation to collaborators Aug 12, 2026
@pull pull Bot added the ⤵️ pull label Aug 12, 2026
@pull
pull Bot merged commit 09f0dc7 into code:main Aug 12, 2026
10 of 11 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants